feat: open Insta360 .insp photos as spheres - #47

Implements the viewer half of #45: .insp photos open as spheres, straight from the file.

An .insp is a JPEG holding both lenses' fisheye circles side by side, plus a trailer at the end that says where each circle sits, how wide each lens sees and how the two lenses are rotated against each other. This reads that trailer in Rust and hands the numbers to the viewer, which projects the two circles on the GPU while drawing. There is no stitched intermediate image and nothing is written next to the original, so nothing is resampled twice and the full resolution of each circle stays available at whatever the viewport can show.

What changes for the user

• Opening an Insta360 photo shows the sphere instead of two circles.
• A new Projection section in the main menu, and Ctrl+D, switch between Equirectangular and Dual Fisheye. Both are always offered, for every image.
• Without a calibration (any other dual fisheye image, or an .insp whose trailer was stripped) the viewer assumes the standard layout, two 180° circles filling the frame, and says so in a notification.
• .insp gets a file type of its own (image/x-insta360-insp) and SphereView declares that it handles it, so the desktop can offer it for these files instead of handing them to a JPEG viewer.

How it is built

The shader is a port of PSV's own MIT dual-fisheye adapter, with its hardcoded 180° and circle size replaced by the per-file calibration. Levelling is not baked into pixels — when the camera's motion sensor reading is used, it will go through sphereCorrection, which is an exact rotation.

Licence

Implemented from published measurements — golblick's format notes, insta360-stitch (MIT OR Apache-2.0) and exiftool — rather than ported from golblick's AGPL code, so this stays MIT. The one dependency added is three, which PSV already requires.

Testing

cargo fmt --all -- --check
cargo test                     29 tests
cargo clippy --all-targets     clean in the new code

• tests/insta360_trailer.rs: the record walk, the padding ambiguity (a 32-byte pad also reads as five zero-length records, which a naive walk trips over), truncation, a bad magic, a trailer size running past EOF, and a calibration string taken verbatim from a real Insta360 ONE file.
• tests/fixtures/synthetic.insp: generated by tools/make_synthetic_insp.py, so it is ours and needs no camera. It goes through the real loader in src/image.rs.
• SPHEREVIEW_TEST_INSP=/path/to/photo.insp cargo test --test insta360_trailer runs against a real camera file locally. None is committed: .insp originals are photographs, and no vendor grants redistribution.
• tests/mime_registration.rs cross-checks the MIME database against the desktop entry for every extension the application opens, so a new format cannot be added to one and forgotten in the other. I also built a throwaway MIME database from the new XML and confirmed GLib resolves synthetic.insp to image/x-insta360-insp while a plain .jpg stays image/jpeg, and that desktop-file-validate accepts the entry.

Beyond the tests I ran the app under Xvfb with software GL and screenshotted it: FRONT reads correctly at the default view, RIGHT at yaw 90 with the seam running through the centre of the view without doubling, BACK at yaw 180, and at pitch 88 the +30° parallel is a clean circle with meridians radiating from the zenith. That check is what caught two bugs in the shader: a missing varying, and a mirrored x axis, because PSV builds its sphere with scale(-1,1,1) and compensates inside its own shaders.

Known limits

• Two conventions are still assumptions, both declared as uniforms so they are one-line changes: which way each lens's image runs along x, and that lens 0 faces +Z. The synthetic fixture cannot settle them because it is generated with the same mapping. A real OneR/X3/X5 file would.
• No seam routing for parallax: near-field objects that sit in both lenses can double at the seam. golblick solves this with a search; this does not attempt it.
• No level sphereCorrection yet — the motion sensor reading is parsed but unused.
• Double-click needs the MIME database installed, not just committed: an .insp resolves to image/jpeg by content sniffing, so the new type only wins once io.github.dynobo.sphereview.mime.xml is installed and update-mime-database has run. The Flathub manifest pins a release tag and does not install the XML yet, so that is a second pull request against a release containing this one. Magic matching is not an option: shared-mime-info offsets count from the start of the file and the Insta360 trailer is at the end, so the type is matched on *.insp.
• .insv video is out of scope.

Refs #45